VPC間の接続をVPCピアリングからAWS Transit Gatewayに切り替えた時の通信の挙動を検証してみた
VPC間の接続をVPCピアリングからAWS Transit Gatewayに切り替えた時の通信の挙動を検証しました。検証の結果、切り替え時にpingコマンドで確認できるレベルの瞬断は発生しないことや、非対称ルーティングになっても通信できることなどが確認できました。
VPCピアリングからAWS Transit Gatewayに切り替える時の注意点を知りたい
こんにちは、自称Transit Gatewayおじさんの のんピ(@non____97)です。
皆さんはTransit Gateway好きですか? 私は好きです。
Transit Gatewayを使い始めるきっかけとして、「多数のVPCを簡単に繋げたい」という理由が多いと考えます。特に、最初からTransit Gatewayを使っているのではなく、段々とVPCが増えていってVPCピアリングではな対応しきれなくなってきたというケースがよく見られます。
そこで、VPC間の接続をVPCピアリングからTransit Gatewayに切り替えた時に、どのような挙動をするのか検証してみようと思います。特に以下の観点で検証してみます。
- 切り替え時の瞬断の発生の有無
- 通信のリクエストはTransit Gateway、レスポンスはVPCピアリングと非対称ルーティングになっても正常に通信できるか
いきなりまとめ
- 切り替え時にpingコマンドで確認できるレベルの瞬断は発生しない
- 通信のリクエストはTransit Gateway、レスポンスはVPCピアリングと非対称ルーティングになっても正常に通信できる
- ルートテーブルの設定反映は即時に行われる
- Transit Gatewayを経由する場合、VPCピアリングを経由する場合と比較して応答速度が0.1msほど遅くなる
検証のシナリオ
検証開始時点ではVPCが2つ存在し、2つのVPC間はVPCピアリングで接続されているものとします。
どちらもVPCピアリングで通信をしている状態から、Transit Gatewayに徐々に切り替えていきます。
まず、Transite Gatewayを作成し、VPCに接続します。そしてVPC AからVPC Bへの通信がTransit Gatewayを経由して行われるようにルートテーブルを変更します。VPC BからVPC Aへの通信については引き続きVPCピアリングを経由して行われるようにしておきます。
最後にVPC BからVPC Aへの通信についてもTransit Gatewayを経由して行われるようにルートテーブルを変更し、VPCピアリングを削除します。
やってみた
リクエストもレスポンスもVPCピアリングを経由するように変更した場合
それではまず、リクエストもレスポンスもVPCピアリングを経由するように変更した場合を確認します。
以下のようにVPCピアリングを作成しています。
そして、各VPCのルートテーブルで対向のVPCに通信を行う場合はVPCピアリングを使用するようにルートを追加しました。
VPC Aのルートテーブル
VPC Bのルートテーブル
この状態でVPC AのEC2インスタンスからVPC BのEC2インスタンスへ疎通確認を行います。
$ ping 10.0.1.75 -c 4 PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. 64 bytes from 10.0.1.75: icmp_seq=1 ttl=64 time=1.46 ms 64 bytes from 10.0.1.75: icmp_seq=2 ttl=64 time=0.923 ms 64 bytes from 10.0.1.75: icmp_seq=3 ttl=64 time=0.912 ms 64 bytes from 10.0.1.75: icmp_seq=4 ttl=64 time=0.907 ms --- 10.0.1.75 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 0.907/1.052/1.467/0.240 ms $ traceroute 10.0.1.75 traceroute to 10.0.1.75 (10.0.1.75), 30 hops max, 60 byte packets 1 10.0.1.75 (10.0.1.75) 0.923 ms 0.898 ms 0.880 ms
無事できました。
リクエストはTransit Gateway、レスポンスはVPCピアリングを経由するように変更した場合
次にリクエストはTransit Gateway、レスポンスはVPCピアリングを経由するように変更した場合を確認します。
Transit Gatewayを作成し、各VPCにTransit Gateway Attachmentを作成します。
作成したTransit GatewayはDefault route table associationおよびDefault route table propagationのどちらも有効化したため、Transit Gateway Route Tableを確認すると以下のように各VPCのTransit Gateway Attachmentへのルートが追加されています。
それでは、VPC AからVPC Bへの通信がTransit Gatewayを経由するようにルートテーブルを編集します。
作業は、以下の流れで行います。
- ルートテーブル変更前に
tracerouteでネットワークの経路を確認する pingでICMPパケットを200ms間隔で50回打ち続ける- 30回目のICMPパケットを送信するタイミングで、VPC AからVPC Bへの通信がTransit Gatewayを経由するようにルートテーブルを更新する
ping実行完了後、tracerouteでネットワークの経路を確認する
作業時のコマンドの結果は以下の通りです。
$ traceroute 10.0.1.75; ping 10.0.1.75 -D -i 0.2 -c 50; traceroute 10.0.1.75 traceroute to 10.0.1.75 (10.0.1.75), 30 hops max, 60 byte packets 1 10.0.1.75 (10.0.1.75) 0.915 ms 0.897 ms 0.880 ms PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. [1638510291.897657] 64 bytes from 10.0.1.75: icmp_seq=1 ttl=64 time=1.52 ms [1638510292.097950] 64 bytes from 10.0.1.75: icmp_seq=2 ttl=64 time=0.967 ms [1638510292.298213] 64 bytes from 10.0.1.75: icmp_seq=3 ttl=64 time=0.916 ms [1638510292.502734] 64 bytes from 10.0.1.75: icmp_seq=4 ttl=64 time=0.923 ms [1638510292.702951] 64 bytes from 10.0.1.75: icmp_seq=5 ttl=64 time=0.915 ms [1638510292.903266] 64 bytes from 10.0.1.75: icmp_seq=6 ttl=64 time=0.915 ms [1638510293.103544] 64 bytes from 10.0.1.75: icmp_seq=7 ttl=64 time=0.927 ms [1638510293.303974] 64 bytes from 10.0.1.75: icmp_seq=8 ttl=64 time=0.936 ms [1638510293.504215] 64 bytes from 10.0.1.75: icmp_seq=9 ttl=64 time=0.904 ms [1638510293.706812] 64 bytes from 10.0.1.75: icmp_seq=10 ttl=64 time=0.998 ms [1638510293.907067] 64 bytes from 10.0.1.75: icmp_seq=11 ttl=64 time=0.918 ms [1638510294.110714] 64 bytes from 10.0.1.75: icmp_seq=12 ttl=64 time=0.906 ms [1638510294.314715] 64 bytes from 10.0.1.75: icmp_seq=13 ttl=64 time=0.927 ms [1638510294.518704] 64 bytes from 10.0.1.75: icmp_seq=14 ttl=64 time=0.912 ms [1638510294.722681] 64 bytes from 10.0.1.75: icmp_seq=15 ttl=64 time=0.903 ms [1638510294.926733] 64 bytes from 10.0.1.75: icmp_seq=16 ttl=64 time=0.927 ms [1638510295.130739] 64 bytes from 10.0.1.75: icmp_seq=17 ttl=64 time=0.926 ms [1638510295.331019] 64 bytes from 10.0.1.75: icmp_seq=18 ttl=64 time=0.874 ms [1638510295.534816] 64 bytes from 10.0.1.75: icmp_seq=19 ttl=64 time=0.981 ms [1638510295.735050] 64 bytes from 10.0.1.75: icmp_seq=20 ttl=64 time=0.908 ms [1638510295.935317] 64 bytes from 10.0.1.75: icmp_seq=21 ttl=64 time=0.922 ms [1638510296.135583] 64 bytes from 10.0.1.75: icmp_seq=22 ttl=64 time=0.921 ms [1638510296.338736] 64 bytes from 10.0.1.75: icmp_seq=23 ttl=64 time=0.927 ms [1638510296.538974] 64 bytes from 10.0.1.75: icmp_seq=24 ttl=64 time=0.916 ms [1638510296.739583] 64 bytes from 10.0.1.75: icmp_seq=25 ttl=64 time=0.905 ms [1638510296.939840] 64 bytes from 10.0.1.75: icmp_seq=26 ttl=64 time=0.916 ms [1638510297.142843] 64 bytes from 10.0.1.75: icmp_seq=27 ttl=64 time=0.977 ms [1638510297.343026] 64 bytes from 10.0.1.75: icmp_seq=28 ttl=64 time=0.917 ms [1638510297.546701] 64 bytes from 10.0.1.75: icmp_seq=29 ttl=64 time=0.899 ms [1638510297.750740] 64 bytes from 10.0.1.75: icmp_seq=30 ttl=64 time=0.926 ms [1638510297.954750] 64 bytes from 10.0.1.75: icmp_seq=31 ttl=64 time=0.924 ms [1638510298.158738] 64 bytes from 10.0.1.75: icmp_seq=32 ttl=64 time=0.930 ms [1638510298.362733] 64 bytes from 10.0.1.75: icmp_seq=33 ttl=64 time=0.915 ms [1638510298.566711] 64 bytes from 10.0.1.75: icmp_seq=34 ttl=64 time=0.910 ms [1638510298.770793] 64 bytes from 10.0.1.75: icmp_seq=35 ttl=64 time=0.913 ms [1638510298.975056] 64 bytes from 10.0.1.75: icmp_seq=36 ttl=64 time=1.28 ms [1638510299.175369] 64 bytes from 10.0.1.75: icmp_seq=37 ttl=64 time=1.05 ms [1638510299.375746] 64 bytes from 10.0.1.75: icmp_seq=38 ttl=64 time=1.11 ms [1638510299.576051] 64 bytes from 10.0.1.75: icmp_seq=39 ttl=64 time=1.04 ms [1638510299.776971] 64 bytes from 10.0.1.75: icmp_seq=40 ttl=64 time=1.63 ms [1638510299.977371] 64 bytes from 10.0.1.75: icmp_seq=41 ttl=64 time=1.05 ms [1638510300.177701] 64 bytes from 10.0.1.75: icmp_seq=42 ttl=64 time=1.04 ms [1638510300.378022] 64 bytes from 10.0.1.75: icmp_seq=43 ttl=64 time=1.03 ms [1638510300.578398] 64 bytes from 10.0.1.75: icmp_seq=44 ttl=64 time=1.03 ms [1638510300.778696] 64 bytes from 10.0.1.75: icmp_seq=45 ttl=64 time=1.01 ms [1638510300.979121] 64 bytes from 10.0.1.75: icmp_seq=46 ttl=64 time=1.06 ms [1638510301.179531] 64 bytes from 10.0.1.75: icmp_seq=47 ttl=64 time=1.11 ms [1638510301.379871] 64 bytes from 10.0.1.75: icmp_seq=48 ttl=64 time=1.03 ms [1638510301.580268] 64 bytes from 10.0.1.75: icmp_seq=49 ttl=64 time=1.09 ms [1638510301.780628] 64 bytes from 10.0.1.75: icmp_seq=50 ttl=64 time=1.05 ms --- 10.0.1.75 ping statistics --- 50 packets transmitted, 50 received, 0% packet loss, time 9883ms rtt min/avg/max/mdev = 0.874/0.991/1.635/0.149 ms traceroute to 10.0.1.75 (10.0.1.75), 30 hops max, 60 byte packets 1 * * * 2 10.0.1.75 (10.0.1.75) 1.625 ms 1.161 ms 1.599 ms
どうやらpingコマンドで確認できるレベルの瞬断は発生していないようです。また、ルートテーブルの編集画面で、変更を保存をクリックして、レスポンスが帰ってきたタイミング(実行結果のicmp_seq=36)で応答速度が約0.1ms遅くなりました。
応答速度の遅延がたまたまの可能性もあるので、同様のコマンドでVPC AからVPC Bへの通信がVPCピアリングを経由するようにルートテーブルを更新する際の応答速度の変化を確認してみました。結果は以下の通りです。
$ traceroute 10.0.1.75; ping 10.0.1.75 -D -i 0.2 -c 50; traceroute 10.0.1.75 traceroute to 10.0.1.75 (10.0.1.75), 30 hops max, 60 byte packets 1 * * * 2 10.0.1.75 (10.0.1.75) 1.123 ms 1.113 ms 1.103 ms PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. [1638510335.630643] 64 bytes from 10.0.1.75: icmp_seq=1 ttl=64 time=1.29 ms [1638510335.831097] 64 bytes from 10.0.1.75: icmp_seq=2 ttl=64 time=1.15 ms [1638510336.031610] 64 bytes from 10.0.1.75: icmp_seq=3 ttl=64 time=1.07 ms [1638510336.232143] 64 bytes from 10.0.1.75: icmp_seq=4 ttl=64 time=1.08 ms [1638510336.432697] 64 bytes from 10.0.1.75: icmp_seq=5 ttl=64 time=1.07 ms [1638510336.633234] 64 bytes from 10.0.1.75: icmp_seq=6 ttl=64 time=1.07 ms [1638510336.833830] 64 bytes from 10.0.1.75: icmp_seq=7 ttl=64 time=1.15 ms [1638510337.034353] 64 bytes from 10.0.1.75: icmp_seq=8 ttl=64 time=1.07 ms [1638510337.234935] 64 bytes from 10.0.1.75: icmp_seq=9 ttl=64 time=1.07 ms [1638510337.435359] 64 bytes from 10.0.1.75: icmp_seq=10 ttl=64 time=1.08 ms [1638510337.635813] 64 bytes from 10.0.1.75: icmp_seq=11 ttl=64 time=1.12 ms [1638510337.836394] 64 bytes from 10.0.1.75: icmp_seq=12 ttl=64 time=1.06 ms [1638510338.036804] 64 bytes from 10.0.1.75: icmp_seq=13 ttl=64 time=1.08 ms [1638510338.237337] 64 bytes from 10.0.1.75: icmp_seq=14 ttl=64 time=1.08 ms [1638510338.437729] 64 bytes from 10.0.1.75: icmp_seq=15 ttl=64 time=1.06 ms [1638510338.638190] 64 bytes from 10.0.1.75: icmp_seq=16 ttl=64 time=1.07 ms [1638510338.838581] 64 bytes from 10.0.1.75: icmp_seq=17 ttl=64 time=1.08 ms [1638510339.039109] 64 bytes from 10.0.1.75: icmp_seq=18 ttl=64 time=1.09 ms [1638510339.239686] 64 bytes from 10.0.1.75: icmp_seq=19 ttl=64 time=1.07 ms [1638510339.440043] 64 bytes from 10.0.1.75: icmp_seq=20 ttl=64 time=1.07 ms [1638510339.640597] 64 bytes from 10.0.1.75: icmp_seq=21 ttl=64 time=1.14 ms [1638510339.840999] 64 bytes from 10.0.1.75: icmp_seq=22 ttl=64 time=1.08 ms [1638510340.041541] 64 bytes from 10.0.1.75: icmp_seq=23 ttl=64 time=1.07 ms [1638510340.241960] 64 bytes from 10.0.1.75: icmp_seq=24 ttl=64 time=1.08 ms [1638510340.442512] 64 bytes from 10.0.1.75: icmp_seq=25 ttl=64 time=1.09 ms [1638510340.642905] 64 bytes from 10.0.1.75: icmp_seq=26 ttl=64 time=1.05 ms [1638510340.843337] 64 bytes from 10.0.1.75: icmp_seq=27 ttl=64 time=1.07 ms [1638510341.043739] 64 bytes from 10.0.1.75: icmp_seq=28 ttl=64 time=1.10 ms [1638510341.244151] 64 bytes from 10.0.1.75: icmp_seq=29 ttl=64 time=1.13 ms [1638510341.444524] 64 bytes from 10.0.1.75: icmp_seq=30 ttl=64 time=1.08 ms [1638510341.644900] 64 bytes from 10.0.1.75: icmp_seq=31 ttl=64 time=1.09 ms [1638510341.845324] 64 bytes from 10.0.1.75: icmp_seq=32 ttl=64 time=1.12 ms [1638510342.045526] 64 bytes from 10.0.1.75: icmp_seq=33 ttl=64 time=0.916 ms [1638510342.246760] 64 bytes from 10.0.1.75: icmp_seq=34 ttl=64 time=0.907 ms [1638510342.450766] 64 bytes from 10.0.1.75: icmp_seq=35 ttl=64 time=0.918 ms [1638510342.654720] 64 bytes from 10.0.1.75: icmp_seq=36 ttl=64 time=0.920 ms [1638510342.858724] 64 bytes from 10.0.1.75: icmp_seq=37 ttl=64 time=0.911 ms [1638510343.062716] 64 bytes from 10.0.1.75: icmp_seq=38 ttl=64 time=0.912 ms [1638510343.266725] 64 bytes from 10.0.1.75: icmp_seq=39 ttl=64 time=0.917 ms [1638510343.470717] 64 bytes from 10.0.1.75: icmp_seq=40 ttl=64 time=0.915 ms [1638510343.674730] 64 bytes from 10.0.1.75: icmp_seq=41 ttl=64 time=0.924 ms [1638510343.878735] 64 bytes from 10.0.1.75: icmp_seq=42 ttl=64 time=0.932 ms [1638510344.082797] 64 bytes from 10.0.1.75: icmp_seq=43 ttl=64 time=0.975 ms [1638510344.283080] 64 bytes from 10.0.1.75: icmp_seq=44 ttl=64 time=0.995 ms [1638510344.483386] 64 bytes from 10.0.1.75: icmp_seq=45 ttl=64 time=0.935 ms [1638510344.686773] 64 bytes from 10.0.1.75: icmp_seq=46 ttl=64 time=0.983 ms [1638510344.886964] 64 bytes from 10.0.1.75: icmp_seq=47 ttl=64 time=0.920 ms [1638510345.090761] 64 bytes from 10.0.1.75: icmp_seq=48 ttl=64 time=0.946 ms [1638510345.294716] 64 bytes from 10.0.1.75: icmp_seq=49 ttl=64 time=0.917 ms [1638510345.498714] 64 bytes from 10.0.1.75: icmp_seq=50 ttl=64 time=0.914 ms --- 10.0.1.75 ping statistics --- 50 packets transmitted, 50 received, 0% packet loss, time 9868ms rtt min/avg/max/mdev = 0.907/1.038/1.295/0.089 ms traceroute to 10.0.1.75 (10.0.1.75), 30 hops max, 60 byte packets 1 10.0.1.75 (10.0.1.75) 0.888 ms 0.871 ms 0.854 ms
今回は、ルートテーブルの編集画面で変更を保存をクリックして、レスポンスが帰ってきたタイミング(実行結果のicmp_seq=33)で応答速度が約0.1ms速くなりました。
どうやら、VPCピアリング、Transit Gatewayどちらを経由するかで応答速度に若干の差があるようです。
それでも、もう少しサンプルが必要だと思ったので、ルートテーブル設定変更前後でそれぞれICMPパケットを100回×3セット繰り返してみます。結果は以下の通りです。
- リクエストもレスポンスもVPCピアリングを経由する場合のpingの結果 (1回目)
$ ping 10.0.1.75 -i 0.2 -c 100 PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. 64 bytes from 10.0.1.75: icmp_seq=1 ttl=64 time=0.901 ms . . . 64 bytes from 10.0.1.75: icmp_seq=100 ttl=64 time=0.947 ms --- 10.0.1.75 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 20051ms rtt min/avg/max/mdev = 0.894/0.945/1.915/0.111 ms
- リクエストもレスポンスもVPCピアリングを経由する場合のpingの結果 (2回目)
$ ping 10.0.1.75 -i 0.2 -c 100 PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. 64 bytes from 10.0.1.75: icmp_seq=1 ttl=64 time=0.889 ms . . . 64 bytes from 10.0.1.75: icmp_seq=100 ttl=64 time=0.924 ms --- 10.0.1.75 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 20028ms rtt min/avg/max/mdev = 0.889/0.942/1.542/0.078 ms
- リクエストもレスポンスもVPCピアリングを経由する場合のpingの結果 (3回目)
$ ping 10.0.1.75 -i 0.2 -c 100 PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. 64 bytes from 10.0.1.75: icmp_seq=1 ttl=64 time=0.886 ms . . . 64 bytes from 10.0.1.75: icmp_seq=100 ttl=64 time=0.929 ms --- 10.0.1.75 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 20070ms rtt min/avg/max/mdev = 0.886/0.933/1.027/0.043 ms
- リクエストはTransit Gateway、レスポンスはVPCピアリングを経由する場合のpingの結果 (1回目)
$ ping 10.0.1.75 -i 0.2 -c 100 PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. 64 bytes from 10.0.1.75: icmp_seq=1 ttl=64 time=1.23 ms . . . 64 bytes from 10.0.1.75: icmp_seq=100 ttl=64 time=0.989 ms --- 10.0.1.75 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 19832ms rtt min/avg/max/mdev = 0.981/1.012/1.230/0.044 ms
- リクエストはTransit Gateway、レスポンスはVPCピアリングを経由する場合のpingの結果 (2回目)
$ ping 10.0.1.75 -i 0.2 -c 100 PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. 64 bytes from 10.0.1.75: icmp_seq=1 ttl=64 time=1.11 ms . . . 64 bytes from 10.0.1.75: icmp_seq=100 ttl=64 time=1.03 ms --- 10.0.1.75 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 19836ms rtt min/avg/max/mdev = 1.014/1.057/1.237/0.053 ms
- リクエストはTransit Gateway、レスポンスはVPCピアリングを経由する場合のpingの結果 (3回目)
$ ping 10.0.1.75 -i 0.2 -c 100 PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. 64 bytes from 10.0.1.75: icmp_seq=1 ttl=64 time=1.19 ms . . . 64 bytes from 10.0.1.75: icmp_seq=100 ttl=64 time=1.08 ms --- 10.0.1.75 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 19843ms rtt min/avg/max/mdev = 1.059/1.107/1.618/0.086 ms
やはり、どうやらTransit Gatewayを経由する場合、VPCピアリングを経由する場合と比較して応答速度が0.1msほど遅くなるようです。
作業後のVPC Aのルートテーブルは以下のように、VPC BのCIDR(10.0.1.0/24)への通信はTransit Gatewayを経由するようにしておきます。
リクエストもレスポンスもTransit Gatewayを経由するように変更した場合
最後に、リクエストもレスポンスもTransit Gatewayを経由するように変更した場合を確認します。
VPC BからVPC Aへの通信がTransit Gatewayを経由するようにルートテーブルを編集します。
作業は、以下の流れで行います。
- ルートテーブル変更前に
tracerouteでネットワークの経路を確認する pingでICMPパケットを200ms間隔で50回打ち続ける- 30回目のICMPパケットを送信するタイミングで、VPC BからVPC Aへの通信がTransit Gatewayを経由するようにルートテーブルを更新する
ping実行完了後、tracerouteでネットワークの経路を確認する
作業時のコマンドの結果は以下の通りです。
$ traceroute 10.0.1.75; ping 10.0.1.75 -D -i 0.2 -c 50; traceroute 10.0.1.75 traceroute to 10.0.1.75 (10.0.1.75), 30 hops max, 60 byte packets 1 * * * 2 10.0.1.75 (10.0.1.75) 1.149 ms 1.125 ms * PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. [1638511512.333160] 64 bytes from 10.0.1.75: icmp_seq=1 ttl=64 time=1.22 ms [1638511512.533538] 64 bytes from 10.0.1.75: icmp_seq=2 ttl=64 time=1.04 ms [1638511512.733899] 64 bytes from 10.0.1.75: icmp_seq=3 ttl=64 time=1.04 ms [1638511512.934334] 64 bytes from 10.0.1.75: icmp_seq=4 ttl=64 time=1.08 ms [1638511513.134733] 64 bytes from 10.0.1.75: icmp_seq=5 ttl=64 time=1.06 ms [1638511513.335134] 64 bytes from 10.0.1.75: icmp_seq=6 ttl=64 time=1.06 ms [1638511513.535562] 64 bytes from 10.0.1.75: icmp_seq=7 ttl=64 time=1.03 ms [1638511513.736023] 64 bytes from 10.0.1.75: icmp_seq=8 ttl=64 time=1.05 ms [1638511513.936373] 64 bytes from 10.0.1.75: icmp_seq=9 ttl=64 time=1.06 ms [1638511514.136886] 64 bytes from 10.0.1.75: icmp_seq=10 ttl=64 time=1.12 ms [1638511514.337221] 64 bytes from 10.0.1.75: icmp_seq=11 ttl=64 time=1.04 ms [1638511514.537561] 64 bytes from 10.0.1.75: icmp_seq=12 ttl=64 time=1.05 ms [1638511514.737723] 64 bytes from 10.0.1.75: icmp_seq=13 ttl=64 time=1.04 ms [1638511514.938163] 64 bytes from 10.0.1.75: icmp_seq=14 ttl=64 time=1.04 ms [1638511515.138610] 64 bytes from 10.0.1.75: icmp_seq=15 ttl=64 time=1.12 ms [1638511515.339099] 64 bytes from 10.0.1.75: icmp_seq=16 ttl=64 time=1.04 ms [1638511515.539532] 64 bytes from 10.0.1.75: icmp_seq=17 ttl=64 time=1.10 ms [1638511515.739867] 64 bytes from 10.0.1.75: icmp_seq=18 ttl=64 time=1.04 ms [1638511515.940278] 64 bytes from 10.0.1.75: icmp_seq=19 ttl=64 time=1.04 ms [1638511516.140720] 64 bytes from 10.0.1.75: icmp_seq=20 ttl=64 time=1.04 ms [1638511516.341168] 64 bytes from 10.0.1.75: icmp_seq=21 ttl=64 time=1.03 ms [1638511516.541641] 64 bytes from 10.0.1.75: icmp_seq=22 ttl=64 time=1.07 ms [1638511516.742077] 64 bytes from 10.0.1.75: icmp_seq=23 ttl=64 time=1.06 ms [1638511516.942541] 64 bytes from 10.0.1.75: icmp_seq=24 ttl=64 time=1.04 ms [1638511517.142982] 64 bytes from 10.0.1.75: icmp_seq=25 ttl=64 time=1.07 ms [1638511517.343365] 64 bytes from 10.0.1.75: icmp_seq=26 ttl=64 time=1.04 ms [1638511517.543915] 64 bytes from 10.0.1.75: icmp_seq=27 ttl=64 time=1.06 ms [1638511517.744301] 64 bytes from 10.0.1.75: icmp_seq=28 ttl=64 time=1.08 ms [1638511517.944696] 64 bytes from 10.0.1.75: icmp_seq=29 ttl=64 time=1.02 ms [1638511518.145067] 64 bytes from 10.0.1.75: icmp_seq=30 ttl=64 time=1.04 ms [1638511518.345549] 64 bytes from 10.0.1.75: icmp_seq=31 ttl=64 time=1.05 ms [1638511518.545912] 64 bytes from 10.0.1.75: icmp_seq=32 ttl=64 time=1.04 ms [1638511518.746281] 64 bytes from 10.0.1.75: icmp_seq=33 ttl=64 time=1.06 ms [1638511518.946690] 64 bytes from 10.0.1.75: icmp_seq=34 ttl=64 time=1.03 ms [1638511519.147025] 64 bytes from 10.0.1.75: icmp_seq=35 ttl=64 time=1.04 ms [1638511519.347362] 64 bytes from 10.0.1.75: icmp_seq=36 ttl=64 time=1.03 ms [1638511519.547864] 64 bytes from 10.0.1.75: icmp_seq=37 ttl=63 time=1.14 ms [1638511519.748240] 64 bytes from 10.0.1.75: icmp_seq=38 ttl=63 time=1.12 ms [1638511519.948640] 64 bytes from 10.0.1.75: icmp_seq=39 ttl=63 time=1.10 ms [1638511520.149244] 64 bytes from 10.0.1.75: icmp_seq=40 ttl=63 time=1.19 ms [1638511520.349649] 64 bytes from 10.0.1.75: icmp_seq=41 ttl=63 time=1.11 ms [1638511520.550035] 64 bytes from 10.0.1.75: icmp_seq=42 ttl=63 time=1.11 ms [1638511520.750454] 64 bytes from 10.0.1.75: icmp_seq=43 ttl=63 time=1.13 ms [1638511520.950896] 64 bytes from 10.0.1.75: icmp_seq=44 ttl=63 time=1.14 ms [1638511521.151279] 64 bytes from 10.0.1.75: icmp_seq=45 ttl=63 time=1.11 ms [1638511521.351696] 64 bytes from 10.0.1.75: icmp_seq=46 ttl=63 time=1.12 ms [1638511521.552133] 64 bytes from 10.0.1.75: icmp_seq=47 ttl=63 time=1.14 ms [1638511521.752526] 64 bytes from 10.0.1.75: icmp_seq=48 ttl=63 time=1.10 ms [1638511521.952925] 64 bytes from 10.0.1.75: icmp_seq=49 ttl=63 time=1.10 ms [1638511522.153334] 64 bytes from 10.0.1.75: icmp_seq=50 ttl=63 time=1.10 ms --- 10.0.1.75 ping statistics --- 50 packets transmitted, 50 received, 0% packet loss, time 9820ms rtt min/avg/max/mdev = 1.024/1.079/1.220/0.046 ms traceroute to 10.0.1.75 (10.0.1.75), 30 hops max, 60 byte packets 1 * * * 2 10.0.1.75 (10.0.1.75) 1.660 ms 1.647 ms *
今回もルートテーブルの編集画面で変更を保存をクリックして、レスポンスが帰ってきたタイミング(実行結果のicmp_seq=37)で応答速度が約0.1ms遅くなりました。
レスポンスもTransit Gatewayを経由するようにルートテーブルを変更した状態で、ICMPパケットを100回×3セット繰り返してみます。結果は以下の通りです。
- リクエストもレスポンスもTransit Gatewayを経由する場合のpingの結果 (1回目)
$ ping 10.0.1.75 -i 0.2 -c 100 PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. 64 bytes from 10.0.1.75: icmp_seq=1 ttl=63 time=1.67 ms . . . 64 bytes from 10.0.1.75: icmp_seq=100 ttl=63 time=1.14 ms --- 10.0.1.75 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 19844ms rtt min/avg/max/mdev = 1.068/1.140/1.675/0.076 ms
- リクエストもレスポンスもTransit Gatewayを経由する場合のpingの結果 (2回目)
$ ping 10.0.1.75 -i 0.2 -c 100 PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. 64 bytes from 10.0.1.75: icmp_seq=1 ttl=63 time=1.38 ms . . . 64 bytes from 10.0.1.75: icmp_seq=100 ttl=63 time=1.10 ms --- 10.0.1.75 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 19845ms rtt min/avg/max/mdev = 1.082/1.147/2.179/0.111 ms
- リクエストもレスポンスもTransit Gatewayを経由する場合のpingの結果 (3回目)
$ ping 10.0.1.75 -i 0.2 -c 100 PING 10.0.1.75 (10.0.1.75) 56(84) bytes of data. 64 bytes from 10.0.1.75: icmp_seq=1 ttl=63 time=1.48 ms . . . 64 bytes from 10.0.1.75: icmp_seq=100 ttl=63 time=1.12 ms --- 10.0.1.75 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 19842ms rtt min/avg/max/mdev = 1.073/1.120/1.485/0.062 ms
やはり、リクエストはTransit Gateway、レスポンスはVPCピアリングを経由するように変更した場合と比較して、約0.1ms遅くなるようですね。
作業後のVPC Bのルートテーブルは以下のように、VPC BのCIDR(10.0.0.0/24)への通信はTransit Gatewayを経由するようにしておきます。
あとはVPCピアリングを削除して、Transit Gatewayへの切り替え作業は完了です。
本番環境でVPCピアリングからAWS Transit Gatewayに切り替える場合は事前に検証をしよう
VPC間の接続をVPCピアリングからAWS Transit Gatewayに切り替えた時の通信の挙動を検証しました。
切り替え時にpingコマンドで確認できるレベルの瞬断は発生しないことが分かり、安心しました。しかし、AP-DB間の通信など大量のトラフィックが発生する場合は通信に影響がある可能性があるので、検証環境などで事前に検証することをお勧めします。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
